Welcome to product
requirement document. After watching this video, you will be able to explain the significance of a product
requirement document, PRD, describe each entry in the PRD for the
given example, and explain the role of user
stories in building the PRD. The initial product requirements document is developed during the conceive phase and
updated in the plan phase. The PRD is focused on
functional requirements, which are capabilities
and functions that a system must be able to
successfully perform, non-functional
requirements defined as performance
specifications that are not behavioral related, and product support
considerations. Let's review an
example of a PRD. We will use the 3D
printer scenario shared in our product
concept document overview. Our first entry
identifies product users. Normally, product users
leverage buyer and user personas that
have been previously developed to describe
key buyers and users. In the case of our
3D printer scenario, marketing will target commercial users to
include automotive, aerospace, defense, educational, and government buyers and users. Next, we list our
functional requirements. Again, these are
requirements that are necessary for the customer to be able to effectively
use the system. These are things
that the customer will actually touch and
experience, for example, the color touch screen, multiple connectivity options, high print volume, and more. When a product is developed using Agile and
Scrum methodologies, a PRD is often augmented by both user stories
and a product backlog. Next, we have non functional
requirements, for example, automated bed leveling,
automated fault identification, secure printing and more. These are not
requirements that are necessarily visible to
the customer, however, they are requirements
that need to be met for the product to be satisfactory. Last but not least, we identify product
support requirements. In this particular case, for the 3D printer, we're going to establish
a 24/7 help desk. We're going to have
troubleshooting and FAQs available through an app and
we're going to in the app, link customers directly to support if they need assistance. A PRD can be augmented
by user stories and a product backlog
if the product is developed using Agile
and Scrum methods. Let's review the
user story format. A user story has two sections. Section 1 is the requirement and Section 2 is the
acceptance criteria. A requirement is
formatted by role, need, and value. If you take a look at our
first user story example, the role as a user, the need, I need
high print volume, and the value, to
print large posters. The solution criteria
is developed to support the need
that the role has, for example, a build volume of 500 by 500 by 600 millimeters, custom sized paper,
automated paper feed. We try to develop
user stories to support each role and
each requirement. All user stories are placed in a prioritized product backlog. The product backlog is
managed by a product owner. The product backlog lists
each user story by number. It prioritizes each user story, and it lists the requirement and the acceptance criteria as previously documented
in the user story. You will have an
opportunity to develop a product requirements
document, user stories, and a product backlog as
part of a hands-on lab covering key product
manager responsibilities in the plan phase. In this video, you
learned that you create the initial PRD in the conceive phase and
update it in the plan phase. A PRD provides details of the following entries,
product users, functional requirements, non-functional requirements,
and support requirements. A PRD contains user stories in the product backlog section.